A personal information managing device of a portable size and weight that stores databases for managing the user's schedule, address book, etc. has been widely used, and a good example of which is an electronic pocketbook. The personal information managing device of this type has been commercialized in various models, and the most advanced ones are furnished with diversified functions including a managing function of an address book, a company list, name cards, and a personal schedule, a document preparing function, etc.
The above conventional models generally include separate databases for each kind of object to be managed (hereinafter, referred to simply as object). For example, when the object is individuals, an address book database having columns of name, address, zip code, telephone number, office, etc. is used, and when the object is companies, a database having columns of company name, business address, zip code, telephone number, facsimile number, responsible person, etc. is used.
However, the above-arranged models have a number of problems. To begin with, the user has to manage objects of different kinds using their respective database managing software programs. For example, even when a home address and a business address are identical, the user has to input the data into the databases of both kinds, thereby making the data input a time-consuming job. Also, the user has to switch the databases if the information he wishes to retrieve belongs to an object of different kind from the one currently used, thereby complicating the process of information retrieval.
In addition, if the user wishes to manage an item, such as a regular meeting, despite the fact that the content of data, that is, the title of the meeting, meeting room, and participants, is more or less the same, the user has to input all the data from the beginning for every single meeting, thereby making the data input as a time and effort demanding job. Further, storing the data redundantly is not preferable for a portable information managing device with a limited storage capacity. Furthermore, when the user wishes to amend the data, he has to do so repetitively if the concerned data are registered in more than one database. This makes the data amendment troublesome; moreover, the user may miss some of these databases and leaves the data unamended in the objects of the corresponding kinds.
Besides the aforementioned problems, the typical model is arranged to manage the schedule per day or per month, and therefore, the typical model can not manage a scheduled item if it extends into the next day or beyond. Thus, if the user wishes to input such a more-than-one-day schedule, he has to input the data in every single day during the period the scheduled item is expected to extend, which is also a time and effort demanding job.